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REMARKS 

This amendment is being filed in response to the Office Action dated February 10, 
201 1. Various claims are amended as shown. No new matter has been added. Claims 6, 12, and 
32 were previously canceled without prejudice. With this filing, claims 1-5, 7-1 1, 13-3 1, and 33- 
35 are pending in the application. 

I. Discussion of the claims and cited references 

The present Office Action rejected claims 1-5, 7-9, 11, 13-16, 17, 19, 20-22, 24- 
27, 28-31, and 33-35 under 35 U.S.C. § 102(e) as allegedly being anticipated by Rana (U.S. 
Patent No. 7,760,737). Claims 10 and 18 were rejected under 35 U.S.C. § 103(a) as allegedly 
being unpatentable over Rana in view of Basso (U.S. Patent No. 7,065,086). 

It is noted that while the present Office Action indicates that claim 23 is rejected, 
no grounds of rejection and/or reasoning in support of a rejection of claim 23 has been set forth 
in the present Office Action. If indeed the present Office Action intended to reject claim 23, it is 
kindly requested that full details of the rejection be set forth in the next communication if a 
rejection of claim 23 is asserted/maintained. 

For the reasons set forth below, the rejections of the claims are respectfully 
traversed. It is therefore kindly requested that the Examiner reconsider and withdraw the 
rejections. 

A. Independent claim 1 

Independent claim 1 as presented herein recites, inter alia, the following 

(emphasis ours): 

"...determining, by said network device, if said received packet fragment is a 
head fragment or a non-head fragment of said packet; 

if the received packet fragment is determined to be the head fi-agment of said 

packet: 

generating, by said network device, a session associated with the head 

fragment; 

processing, by said network device, the head fi-agment to determine a 
destination address for said head fi-agment, said generated session being created to store 
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forwarding information and having a period of time to store said forwarding 
information, including said determined destination address, for said packet or a 
fragment thereof; and 

updating, by said network device at least one non-head fragment of said 
packet to write said destination address, which is obtained from said generated session, 
into a destination address field of said at least one non-head fragment of said packet to 
enable said at least one non-head fragment to be forwarded to same said destination 
address as said head fragment; and 

forwarding said head fragment and said at least one non-head fragment to 

same said destination address for reassembly back into said packet at said destination 

address" 

Support for the above recitations of amended claim 1 can be found in at least page 
8, lines 24-25; page 11, lines 25-25 and claim 6 as originally filed; page 8, lines 13-16; page 13, 
lines 17-18; and elsewhere throughout the present application. It is respectfully submitted that 
Rana does not teach at least the above recitations of claim 1 . 

Various recitations above of claim 1 will be discussed in turn below: 

(1) "determining, by said network device, if said received packet fragment is a 
head fragment or a non-head fragment of said packet" 

The present Office Action cites column 4, lines 10-13 of Rana as allegedly 
teaching this recitation of claim 1. This cited passage of Rana states that "In addition to 
associating a session id with the data packet, PDU assembler 26 also extracts fragment 
information from the header of the data packet and determines whether the data packet is a 
fragment' (emphasis ours). 

Rather than teaching the recitations of claim 1, the above cited/quoted passage of 
Rana teaches that information "from the header of the data packet" is extracted in order to 
determine "whether the data packet is a fragment." Stated in another way, Rana is completely 
silent with respect to determining whether a "received packet fragment is a head fragment or a 
non-head fragment of said packet" as recited in claim 1 — rather, Rana simply determines 
whether or not a data packet is a fragment — ^Rana does not make any distinctions/determinations 
between types of fragments, such as if his fragment is a head fragment or a non-head fragment, 
as set forth in claim 1. 
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(2) "generating a session. .. said generated session being created to store 
forwarding information and having a period of time to store said forwarding information, 
including said determined destination address" 

The present Office Action cites column 4, lines 17-19 and column 6, lines 62-65 
of Rana as allegedly teaching the "session" recited in previously presented claim 1. In particular, 
the present Office Action relies upon the "session id" of Rana. 

It is respectfully submitted that Rana does not teach the "session" of claim 1 as 
previously presented and as amended herein. 

Column 3, lines 56-64 of Rana provides further details regarding his "session" 
and "session id," and is reproduced below (emphasis ours): 

"y4 session, or traffic flow, is comprised of all the data packets 
that form a unique session across the network, for example, a session 
could be composed of a TCP/IP session for email or web browsing, a 
UDP session for streaming video, or any other complete traffic flow 
across the nehvork. The queue engine assigns a session id to the first data 
packet received for a new session, and each subsequent packet in the 
session is associated with that session id" 

Thus, it is abundantly clear from the above-quoted passage that Rana's "session" 
is a "traffic flow" of the data packets across the network. In comparison to Rana, claim 1 as 
amended herein recites "said generated session being created to store forwarding 
information. . . ' Rana is completely silent with respect to his session being created to "store 
forwarding information" — his session is just a traffic flow of packets and was not specifically 
created for the purpose of storing forwarding information, and his "session id" is created to 
identify the particular traffic flow of packets. 

(3) "updating... to write said destination address, which is obtained from said 
generated session, into a destination address field of said at least one non-head fragment of said 
packet" 

Page 3 of the present Office Action cites column 6, lines 37-45 as allegedly 
teaching "applying. . . said destination address which is obtained fi-om said generated session to at 
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least one non-head fragment of said packet" of previously presented claim 1 . More particularly, 
the present Office Action asserts that this passage of Rana teaches "assign unique id (destination 
address, DIP) to fragments or stream." Thus, it appears that the present Office Action is 
interpreting Rana's "unique id" as being one and the same as a "destination address." 

It is respectfijUy submitted that the interpretation of Rana by the present Office 
Action to reject claim 1 is in error. Rana's "unique id" is not a "destination address." 

Claim 1 is amended herein so as to provide still further distinction over Rana and 
in particular now recites "updating... to write said destination address, which is obtained from 
said generated session, into a destination address field of said at least one non-head fragment 
of said packet" (emphasis ours). 

Column 6, lines 37-45 of Rana (relied upon by the present Office Action), as well 
as column 4, lines 1-9 of Rana, are reproduced below, (emphasis ours): 

"[The] session id is a location in session CAM 38 which is associated 
with the unique signature used to identify each session. The unique 
signature is comprised of various fields extracted from the header by PDU 
assembler 26. For example, a session could be identified and assigned a 
session id based upon the source address, destination address, source port, 
destination port, protocol fields, and any other field or combination of 
fields from the header of the data packet which form a unique identifier 
based on the properties of the session... FIG. 3a shows an example of the 
fields that may be extracted from the headers of each PDU by PDU 
assembler 26 from FIG. 1. FIG. 3 a shows such fields as source address 
(SIP) and port (SP), destination address (DIP) and port (DP) and protocol 
(prot) extracted as examples of fields that can be used to assign a unique 
identifier to the associated data stream.'' 



From the above-quoted and other passages of Rana, it is abundantly clear that 
what Rana does is to assign each of his streams with a "session id" that operates as a "unique 
identifier" of the session. As explained by Rana above, the "unique identifier" is assigned from 
or otherwise obtained or computed from certain fields in the data packet, such as source address, 
destination address, etc. 

The passages of Rana relied upon by the present Office Action merely explain 
that the unique identifier (the session id) is computed from certain fields of the data packet and 
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assigned to the stream and stored in a . It is respectfully submitted that this teaching of Rana is 
different than what is recited in claim 1. More particularly, Rana computes/obtains a unique id 
from a destination address or other field of the data packet, and then assigns the unique id to the 
stream that the packet belongs to, whereas in comparison claim 1 recites "write said destination 
address... into a destination address field of said at least one non-head fragment." A graphical 
representation of this difference is that Rana performs: extracting destination address fi-om 
destination address field of a packet^obtaining unique/session id fi-om extracted destination 
address-^ writing unique/session id into a content addressable memory (CAM) 38. A non- 
limiting example embodiment corresponding to claim 1 can be graphically represented as: obtain 
destination address fi-om session^write obtained destination address into destination address 
field of fragment. 

It is respectfully submitted that Rana cannot reasonably and logically be 
interpreted to be the same as the "write said destination address... into a destination address field 
of said at least one non-head fragment" recited in claim 1. Such an interpretation would require 
Rana to extract the destination address from the destination address field of the fragment, 
compute the unique/session id from the extracted destination address, and then write the original 
destination address back into the destination address field into the fragment. This interpretation 
would be non-sensical because Rana does not and would have no reason to be overwriting a 
destination address with itself in a fragment —Rana' s primary purpose is to determine a 
session/unique id to write into the CAM 38, and his unique/session id is not a destination 
address. 

(4) "forwarding said head fragment and said at least one non-head fragment to 
same said destination address for reassembly back into said packet at said destination address" 

Rana does not forward his fragments to the same destination address for 
reassembly at the destination address. As clearly shown in Figure 1, Figures 4A-4B, and 
described in column 4, lines 35-55 of Rana, Rana instead provides his engine 10 with a fragment 
reassembly unit 28. The fragment reassembly unit 28 operates to use a reassembly algorithm of 
Figures 4A-4B to reassemble the fragments prior to forwarding to the destination address written 
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into the destination address field of the packet. The fi-agment reassembly unit 28 of Rana is in 
the same device/engine 10 that processed his fragments, and is not the destination address 
indicated in the destination address field of his fragments. 

Accordingly, since Rana reassembles his fragments at the fragment reassembly 
unit 28, rather than at the destination address, Rana does not teach the recitations in claim 1 of 
"forwarding said head fi-agment and said at least one non-head fi-agment to same said destination 
address for reassembly back into said packet at said destination address." 

Furthermore, claim 1 recites "...to enable said at least one non-head fragment to 
be forwarded to same said destination address as said head fragment." Rana further does not 
teach these recitations, since he reassembles his fragments at his fi-agment reassembly unit 28. 
The output from Rana's engine 10 (having his fragment reassembly unit 28) are longer 
"fragments" because the fragments have been reassembled back into a packet-therefore and in 
contrast to claim 1, Rana would be forwarding an assembled packet, rather than fragments to be 
assembled back into the packet, to the destination address. 

Accordingly, in view of at least the foregoing reasons that Rana does not teach the 
various recitations of claim 1, it is respectfiiUy submitted that claim 1 is allowable over Rana. 

B. Other independent claims 

The other independent claims 9, 11, 13, 17, 20, 28, and 33 as presented herein 
contain some recitations generally similar to some of the recitations of claim 1 that are not taught 
by Rana. For example, at least the following recitations (emphasis ours) are not taught by Rana, 
as previously alluded to above pertaining to the session and/or write or writing the destination 
address into the destination address field: 

- In claim 9: ""said generated session being created to store forwarding 
information and having a period of time to store said forwarding information, including the 
determined destination address, for the packet or a fragment thereof and ''...write the 
determined destination address... into a destination address field of the any corresponding 
non-head fragment of said packet." 
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- In claim 1 1 : "said generated session having a period of time to store forwarding 
information for the packet or a fragment thereof and ". . overwriting a destination address field 
of said any corresponding non-head fragment with said obtained destination address.'' 

- In claim 13: ''said generated session being created to store forwarding 
information and having a period of time to store said forwarding information, including said 
determined destination address, for said packet or a fragment thereof and ''...write the 
destination address... into a destination address field of said any corresponding non-head 
fragment of said packet." 

- In claim 17: "said generated session being created to store forwarding 
information and having a period of time to store said forwarding information, including said 
determined destination address, for said packet or a fragment thereof and "...write the 
destination address... into a destination address field of said any corresponding non-head 
fragment of said packet." 

- In claim 20: "said generated session being created to store forwarding 
information and having a period of time to store said forwarding information, including a 
destination address, for said packet or a fragment thereof and ". ..write said destination address 
which is obtained from said generated session into respective destination address fields of said 
non-head fragments." 

- In claim 28: "said generated session being created to store fonvarding 
information and having a period of time to store said forwarding information, including storage 
of the determined destination address, for said packet or a fragment thereof, and... to write the 
stored destination address... into a destination address field of said any corresponding non-head 
fragment of said packet." 

- In claim 33: "an overwrite of a destination address field of said any 
corresponding non-head fragment with said stored destination address." 

II. Conclusion 

If there are any informalities or questions that can be addressed via telephone, the 
Examiner is encouraged to contact the undersigned attorney at (206) 407-1574. 
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The Director is authorized to charge any additional fees due by way of this 
response, or credit any overpayment, to our Deposit Account No. 500393. 

All of the claims remaining in the application are believed to be allowable. 
Favorable consideration and a Notice of Allowance are earnestly solicited 



RespectfiiUy submitted, 

Schwabe, Williamson & Wyatt 

/Dennis M. de Guzman/ 



Dennis M. de Guzman 
Registration No. 41,702 



1420 Fifth Avenue, Suite 3400 
Seattle, Washington 98101 
Phone: (206)407-1574 
Fax: (206)292-0460 
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